Skip Headers

Oracle® Database High Availability Overview 10g Release 2 (10.2) Part Number B14210-01 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# 4 High Availability Architectures

This chapter describes high availability architectures in an Oracle environment. It includes the following sections:

- Oracle Database High Availability Architectures

- Choosing the Correct High Availability Architecture

- Assessing Other Architectures

## 4.1 Oracle Database High Availability Architectures

Oracle Database 10g provides a full range of capabilities to protect from all causes of system downtime, both planned and unplanned. Table 4-1 shows the outage types and the Oracle database capabilities and features that most effectively prevent, tolerate, or repair each outage type.

Table 4-1 Oracle Database High Availability Architectures

Outage Type | Database Capabilities and Features
--- | ---
Unplanned |
Computer failures | Oracle Database 10g with RAC Oracle Database 10g with Data Guard Oracle Database 10g with Streams Fast-Start Fault Recovery
Storage failures | Automatic Storage Management Recovery Manager Flash Recovery Area
Human errors | Oracle Security Features Oracle Flashback Technology LogMiner
Data corruptions | Block Checking Block Checksumming Hardware Assisted Resilient Data (HARD) Initiative Oracle Database 10g with Data Guard Oracle Database 10g with Streams Recovery Manager Flash Recovery Area
Site failures | Oracle Database 10g with Data Guard Oracle Database 10g with Streams Recovery Manager
Planned |
Data changes | Online Reorganization and Redefinition Oracle Database 10g with Data Guard Oracle Database 10g with Streams
System changes | Automatic Storage Management Dynamic Resource Provisioning Rolling patch updates and system upgrades using Oracle Database 10g with RAC Rolling release upgrades and system upgrades using Oracle Database 10g with Data Guard or Oracle Database 10g with Streams Platform Migrations and Database Upgrades with Transportable Tablespace

This section describes the following top database architectures that address various high availability business needs:

- Oracle Database 10g

  Oracle Database 10g running a single database on a standalone machine contains significant high availability features and capabilities. For more information, see Chapter 2, "Oracle Database High Availability Solutions".

- Oracle Database 10g with RAC

  Oracle Real Application Clusters (RAC) builds upon the features and capabilities of Oracle Database 10g. RAC comprises several Oracle instances running on many clustered machines that access a shared database residing on shared disk. RAC combines the processing power of these multiple interconnected computers to provide system redundancy, scalability, and high availability. Application scale in a RAC environment to meet increasing data processing demands without changing the application code. In addition, allowing maintenance operations to occur on a subset of components in the cluster while the application continues to run on the rest of the cluster can reduce planned downtime.

- Oracle Database 10g with Data Guard

  Oracle Data Guard builds upon the features and capabilities of Oracle Database 10g. Data Guard maintains up to nine standby databases—each of which is a real-time copy of the production database—to protect against all threats: computer failures, storage failures, human errors, data corruptions, and site failures. If a failure occurs on the production (primary) database, data processing can fail over to one of the standby databases (which will become the new primary database). In addition, planned downtime for maintenance can be reduced because production processing can quickly and easily switch over from the current primary database to a standby database, and then back again.

- Oracle Database 10g with RAC and Data Guard - MAA

  Maximum Availability Architecture (MAA) combines the scalability and availability advantages of RAC with the site protection capabilities of Data Guard. An MAA environment consists of a site containing a RAC production database, along with a second site containing a cluster that either hosts both logical and physical standby databases, or at least one physical or logical standby database. This architecture provides the most comprehensive set of solutions for both unplanned and planned outages because it inherits the capabilities and advantages of both the Oracle Database 10g with RAC and Oracle Database 10g with Data Guard architectures.

- Oracle Database 10g with Streams

  Oracle Streams enables the propagation and management of data, transactions, and events in a data stream either within a database, or from one database to another. Similar to Oracle Database 10g with Data Guard, Oracle Database with Streams can capture database changes, propagate them to destinations, and apply the changes at these destinations. Using a Streams environment may require additional administrative overhead, but it offers increased flexibility that might be required to meet specific business requirement.

Oracle provides a wide array of high availability architectural solutions. The Oracle Database 10g architecture contains many availability features and assets that are used by all other architectures and is the starting point for most customers. Oracle Database 10g with RAC, Oracle Database 10g with Data Guard, and Oracle Database 10g with Streams provide additional high availability capabilities in addition to the Oracle Database 10g capabilities. MAA incorporates both RAC and Data Guard advantages and represents the architecture with maximum availability. Choosing an architecture with more availability features does not necessarily lead to higher costs. As a matter of fact, RAC technology and GRID computing enable a more available and resilient architecture to be attained with lower total cost of ownership than most legacy high availability features. Figure 4-1 illustrates the hierarchy of the different high availability architectures.

Figure 4-1 Hierarchy of High Availability Architectures

Description of the illustration maxav032.gif

The following sections provide further details on the various Oracle database high availability architectures:

- Oracle Database 10g

- Oracle Database 10g with RAC

- Oracle Database 10g with Data Guard

- Oracle Database 10g with RAC and Data Guard - MAA

- Oracle Database 10g with Streams

### 4.1.1 Oracle Database 10g

Oracle provides high availability features that can be used in any of the database architectures. These features make the standalone database on a single machine attractive and available:

- Oracle Flashback Technology

- Automatic Storage Management

- Fast-Start Fault Recovery

- Recovery Manager

- Flash Recovery Area

- Online Reorganization and Redefinition

### 4.1.2 Oracle Database 10g with RAC

Oracle Database 10g with RAC architecture uses Real Application Clusters and is an inherently high availability system.The clusters that are typical of RAC environments can provide continuous service for both planned and unplanned outages. RAC build higher levels of availability on top of the standard Oracle features. All single instance high availability features, such as flashback technologies and online reorganization, apply to RAC as well.

In addition to the standard Oracle features, RAC exploits the redundancy that is provided by clustering to deliver availability with n - 1 node failures in an n-node cluster. All users have access to all nodes as long as there is one available node in the cluster.

This architecture provides the following benefits:

- Fast node (measured in minutes) and instance failover (measured in seconds)

- Integrated and intelligent connection and service failover across various instances

- Planned node, instance, and service switchover and switchback

- Rolling patch upgrades

- Rolling release upgrades of Oracle Clusterware

- Multiple active instance availability and scalability across multiple nodes

- Comprehensive manageability that integrates database and cluster features

- Extensive cluster and application services that allows the database and application services to be restarted or relocated in case of failures

Figure 4-2 shows Oracle Database 10g with RAC architecture.

Figure 4-2 Oracle Database 10g with RAC Architecture

Description of the illustration haovw002.gif

### 4.1.3 Oracle Database 10g with Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database. If the production database becomes unavailable due to a planned or unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster technologies to provide a high level of data protection and availability. With Data Guard, administrators can optionally improve production database performance by diverting resource-intensive backup and reporting operations to standby systems.

Using a backup copy of the primary database, it is possible to create up to nine standby databases and integrate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and applying the redo to the standby database. Similar to a primary database, a standby database can be either an Oracle single-instance or RAC database.

A standby database can be either a physical standby database or a logical standby database. A physical standby database provides a physically identical copy of the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. A physical standby database is synchronized with the primary database through Redo Apply, which recovers the redo data received from the primary database and applies it to the physical standby database. A physical standby database can be used for business purposes other than disaster recovery on a limited basis.

Physical standby databases provide these advantages:

- Protection from user errors and logical corruptions

- Protection from disasters and site failures if located remotely

- Fast site and database failover (less than 1 minute to 5 minutes)

- Fast-start failover provides the ability to automatically, quickly, and reliably fail over to a designated, synchronized standby database in the event of primary database failure

- Fast site and database planned switchovers for maintenance

- Using Flashback Database, a Redo Apply standby database can diverge for reporting or testing purposes and resynchronize with its primary database once complete

- Backups can be taken from the physical standby database instead of the production database, relieving the load on the production database

- Read-only capability, resulting in better use of system resources

- Greater support for fast application notification and application callouts resulting in better full-stack application failover

A logical standby database can be used for other business purposes in addition to disaster recovery. Users can access a logical standby database for queries and reporting purposes. Using a logical standby database, it is possible to upgrade Oracle database software and patch sets with minimal downtime. Therefore, a logical standby database can be concurrently used for data protection, reporting, and database upgrade purposes.

In addition to disaster recovery and data protection, logical standby databases provide the following benefits:

- Enable the standby database to be open for normal operations with both read-only and read/write accessibility

- Enable additional objects to be built and maintained

- Enable rolling database upgrades of the production database

A recommended configuration for many cases includes both physical and logical standby databases. They can reside on the same database machine or cluster, but they should be remote from the production database. The physical standby database can be reserved for failovers in case of disaster, and the logical standby database can continue to be used for reporting. The physical standby database provides a faster apply technology because redo logs do not have to be converted to SQL.

Figure 4-3 shows the production database at the primary site and the standby databases at the secondary site.

Figure 4-3 Oracle Database 10g with Data Guard Architecture on Primary and Secondary Sites

Description of the illustration maxav020.gif

See Also: Oracle Data Guard Concepts and Administration for more information about datatypes supported by logical standby databases The papers about standby databases at `http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm`

### 4.1.4 Oracle Database 10g with RAC and Data Guard - MAA

RAC and Data Guard provide the basis of Oracle Database 10g - MAA. Maximum Availability Architecture (MAA) provides the most comprehensive architecture for reducing downtime for scheduled outages and preventing, detecting, and recovering from unscheduled outages. The recommended MAA has two identical sites. The primary site contains the RAC primary database, and the secondary site contains a RAC standby database.

Identical site configuration is recommended to ensure that performance is not sacrificed after a failover or switchover. Symmetric sites also enable processes and procedures to be kept the same between sites, making operational tasks easier to maintain and execute.

MAA encompasses RAC, Data Guard, and a set of recommended best practices for configuring and managing the architecture as well as recovering from various outages. For more information, visit the MAA Web site at:

    http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

Figure 4-4 provides an overview of Oracle Database 10g with RAC and Data Guard - MAA.

Figure 4-4 Oracle Database 10g with RAC and Data Guard - MAA

Description of the illustration maxav004.gif

### 4.1.5 Oracle Database 10g with Streams

Oracle Streams is meant for information sharing and distribution. It can also provide an efficient and highly available architecture.

Oracle Database 10g with Streams provides granularity and control over what is replicated and how it is replicated. It supports bidirectional replication, data transformations, subsetting, custom apply functions, and heterogeneous platforms. It also gives users complete control over the routing of change records from the primary database to a replica database. The capture of data changes can be performed at the primary database or downstream at a replica database. This enables users to build hub and spoke network configurations that can support hundreds of replica databases.

Oracle Database 10g with Streams should be evaluated if one or more of the following conditions are true:

- A full active/active site configuration is required, including bidirectional changes

- Site configurations are on heterogeneous platforms

- Different character sets are required between the primary database and its replicas

- Fine control of information and data sharing are required

- More investment and expertise to build and maintain an integrated high availability solution is available

For disaster recovery, Data Guard is Oracle's recommended solution.

Figure 4-5 shows Oracle Database 10g with Streams with local capture running at the primary database.

Figure 4-5 Oracle Database 10g with Streams

Description of the illustration maxav019.gif

## 4.2 Choosing the Correct High Availability Architecture

This section summarizes the advantages of the high availability architectures discussed in this chapter and provides guidelines for you to choose the correct high availability architecture for your business.

Oracle Database 10g with RAC and Oracle Database 10g with Data Guard are the most common Oracle high availability architectures, and each provides very significant high availability advantages. MAA provides the most redundant and robust high availability architecture. It prevents, detects, and recovers from different outages to meet stringent RTO and RPO requirements, as well as preventing or minimizing downtime for maintenance. Oracle Database 10g with Streams is an alternative high availability solution, but it requires more customization and administrative effort, and may not be as transparent to the application.

The baseline high availability architecture is Oracle Database 10g. Consider using:

- Oracle Database 10g with RAC if:

  - Maximum Recovery Time Objective (RTO) for instance or node failure is in seconds or minutes

  - Database scalability beyond one instance or node is required

- Oracle Database 10g with Data Guard if:

  - Maximum RTO for instance or node failure is in seconds to minutes or more

  - Maximum RTO for data corruption or site failure is less than 1 minute to 5 minutes

- MAA if:

  - Projected planned maintenance is in hours or less for each year

  - Both RAC and Data Guard are required

- Oracle Database 10g with Steams if active/active replicated system or heterogeneous solution is required

Table 4-2 identifies the additional capabilities provided by the architectures that build upon Oracle Database 10g.

Table 4-2 Additional Capabilities of High Level Oracle High Availability Architectures

Oracle High Availability Architecture | Key Characteristics and Additional Capabilities
--- | ---
Oracle Database 10g with RAC | Transparent to application Fast repair for human error Fast failover for computer failure and storage failure Scalability beyond a single system Reduced downtime for computer maintenance
Oracle Database 10g with Data Guard | Transparent to application Fast repair for human error Fast failover for computer failure, storage failure, and data corruption Protection from site failure Reduced downtime for computer or site maintenance
Oracle Database 10g with RAC and Data Guard - MAA | Transparent to application Fast repair for human error Fast failover for computer failure, storage failure, and data corruption Protection from site failure Scalability beyond a single system Reduced downtime for computer or site maintenance
Oracle Database 10g with Streams Foot 1 | Fast repair for human error Replica database(s) available for read/write use Provides heterogeneous platform support Fast failover for computer failure and storage failure Protection from site failure Reduced downtime for computer or site maintenance

Footnote 1 Requires planning and overhead to make solution robust

Table 4-3 shows the attainable recovery times for all types of unplanned downtime for each Oracle high availability architecture.

Table 4-3 Attainable Recovery Times for Unplanned Outages

Outage Type | Oracle Database 10g | RAC | Data Guard | MAA | Streams
--- | --- | --- | --- | --- | ---
Computer failure | Minutes to hoursFoot 1 | No downtimeFoot 2 | Seconds to 5 minutes | No downtime | No downtime
Storage failure | No downtimeFoot 3 | No downtime3 | No downtime3 | No downtime3 | No downtime3
Human error | < 30 minutesFoot 4 | < 30 minutes4 | < 30 minutes4 | < 30 minutes4 | < 30 minutes4
Data corruption | No downtimeFoot 5 Minutes to hoursFoot 6 | No downtime5 Minutes to hours6 | No downtime5 Seconds to 5 minutes | No downtime5 Seconds to 5 minutes | No downtime5 Seconds to 5 minutes
Site failure | Hours to days | Hours to days | Seconds to 5 minutesFoot 7 | Seconds to 5 minutes7 | Seconds to 5 minutes7

Footnote 1 Recovery time consists largely of the time it takes to restore the failed system
Footnote 2 Database is still available, but portion of application connected to failed system is temporarily affected
Footnote 3 Storage failures are prevented by using ASM with mirroring and its automatic rebalance capability
Footnote 4 Recovery time for human errors depend primarily on detection time. If it takes seconds to detect a malicious DML or DLL transaction, it typically only requires seconds to flashback the appropriate transactions. Longer detection time usually leads to longer recovery time required to repair the appropriate transactions. An exception is undropping a table, which is literally instantaneous regardless of detection time.
Footnote 5 No downtime if data corruptions are prevented by implementing HARD
Footnote 6 Recovery time depends on the age of the backup used for recovery and the number of log changes scanned to make the corrupt data consistent with the database
Footnote 7 Recovery time indicated applies to database and existing connection failover. Network connection changes and other site-specific failover activities may lengthen overall recovery time.

Table 4-4 shows the attainable recovery times for all types of planned downtime for each Oracle high availability architecture.

Table 4-4 Attainable Recovery Times for Planned Outages

Outage Type | Oracle Database 10g | RAC | Data Guard | MAA | Streams
--- | --- | --- | --- | --- | ---
System changes - Dynamic Resource Provisioning | No downtime | No downtime | No downtime | No downtime | No downtime
System changes - Rolling Upgrades | System level upgrade | Minutes to hours | No downtime | No downtime | No downtime | No downtime
Cluster or site wide upgrade | Minutes to hours | Minutes to hours | Seconds to 5 minutes | Seconds to 5 minutes | Seconds to 5 minutes
Storage migration | No downtimeFoot 1 | No downtime1 | No downtime1 | No downtime1 | No downtime1
Database one-off patch | Minutes to hours | No downtimeFoot 2 | Minutes to hours | No downtime2 | No downtime
Database patchset and version upgrade | Minutes to hours | Minutes to hours | Seconds to 5 minutes | Seconds to 5 minutes | Seconds to 5 minutes
Platform migration | Minutes to hours | Minutes to hours | Minutes to hours | Minutes to hours | Seconds to 5 minutes
Data changes - Online Reorganization and Redefinition | No downtime | No downtime | No downtimeFoot 3 | No downtime3 | No downtime3

Footnote 1 ASM automatically rebalances stored data when disks are added or removed while the database remains online
Footnote 2 For qualified one-off patches only
Footnote 3 Tables can be reorganized online using the `DBMS_REDEFINITION` package. However, the online changes are not supported by SQL Apply or data capture, and therefore the effects of this subprogram are not visible on the logical standby or replica database. For more information, see Oracle Data Guard Concepts and Administration or Oracle Streams Replication Administrator's Guide.

## 4.3 Assessing Other Architectures

There are other Oracle and non-Oracle high availability and enterprise computing architectures. This section focuses on the most common variants.

Table 4-5 describes common alternative high availability architecture, their disadvantages, and the recommended Oracle high availability architectures.

Table 4-5 Comparison of High Availability Architectures

Alternative Architecture | Disadvantages | Recommended Oracle Architecture
--- | --- | ---
Single instance database on hardware cluster | Node failure requires restart, storage remastering, and reconnect for all application connectors No protection from disaster and site failure No protection against data corruptions beyond Oracle Database 10g capabilities Limited ability to reduce downtime for system rolling upgrades Inability to reduce downtime for Oracle upgrades Under-utilized hardware resources No database server scalability beyond one node Inability to offload database activities such as backup or reporting | Oracle Database 10g with RAC Oracle Database 10g with Data Guard Oracle Database 10g with RAC and Data Guard - MAA
Remote mirrored single instance database | High network utilization No protection against data corruptions beyond Oracle Database 10g capabilities Site failure requires instance restart, storage remastering, and reconnect for all applications connections No database server scalability beyond primary node(s) Inability to offload database activities such as backup or reporting Inability to reduce downtime for rolling upgrades Customization required | Oracle Database 10g with Data Guard Oracle Database 10g with RAC and Data Guard - MAA
RAC database in a stretch cluster configuration | No protection against data corruptions beyond Oracle Database 10g capabilities Limited protection against site failures with regional impact Limited ability to reduce downtime for rolling upgrades High network utilization Limited by distance between nodes in cluster As network latency increases, application performance can be impacted significantly | Oracle Database 10g with Data Guard Oracle Database 10g with RAC and Data Guard - MAA
RAC database with standby database on same site | No protection from site failures | Oracle Database 10g with RAC and Data Guard - MAA
Single instance database with standby database on same site | No protection from site failures Limited ability to reduce downtime for rolling upgrades | Oracle Database 10g with RAC and Data Guard - MAA

Table 4-6 describes common traditional enterprise computing architectures, their disadvantages, and the recommended Oracle enterprise computing architectures.

Table 4-6 Comparison of Enterprise Computing Architectures

Traditional Architecture | Disadvantages | Recommended Architecture
--- | --- | ---
Monolithic database server | High cost Fixed scalability Not flexible to changing capacity and resource demands | Database Server Grid
Monolithic storage array | High cost Fixed scalability Not flexible to changing capacity and resource demands | Database Storage Grid

- See Also: "High Availability and Grid Computing" Oracle Resilient Low-Cost Storage Initiative Web site at
      http://www.oracle.com/technology/deploy/availability/htdocs/lowcoststorage.html